Narrow Band Internet-of-Things (NB-IoT) is a narrowband (180 KHz bandwidth) system being developed for cellular Internet-of-Things (IoT) by the Third Generation Partnership Project (3GPP). The system is based on Long Term Evolution (LTE) systems, and addresses optimized network architecture and improved indoor coverage for a massive number of devices with any of the following characteristics: low throughput (e.g., 2 Kbps); low delay sensitivity (e.g., ˜10 seconds); ultra-low device cost (e.g., below 5 dollars); and low device power consumption (e.g., battery life of 10 years).
It is envisioned that each cell (e.g., ˜1 Km2) in this system will serve thousands (e.g., ˜50,000) devices such as sensors, meters, actuators, and other devices. It is imperative that this system be able to provide good coverage for its devices, which are often located deep indoors (e.g., underground in basements, or even built into walls of a building) and have limited or no possibility for battery charging. Although many different types of devices are envisioned, for the sake of simplicity they will be interchangeably referred to herein as user equipment (UEs) or wireless devices.
In order to make it possible to deploy NB-IoT using only one re-farmed GSM carrier and support lower manufacturing costs for NB-IoT UEs, the bandwidth has been reduced to one physical resource block (PRB) of size 180 KHz divided into several subcarriers.
For frequency division duplex (FDD) (i.e., the transmitter and the receiver operate at different carrier frequencies), only half-duplex mode needs to be supported in the UE. The lower complexity of the devices (e.g., only one transmission/receiver chain) means that some repetition might also be needed in normal coverage. Further, to alleviate UE complexity, the working assumption is to have cross-subframe scheduling. That is, a transmission is first scheduled on an Enhanced Physical Downlink Control Channel (E-PDCCH, also known as narrowband Physical Downlink Control Channel (NB-PDCCH or NPDCCH). Then, the first transmission of the actual data on the narrowband Physical Downlink Shared Channel (NB-PDSCH or NPDSCH) is carried out after the final transmission of the NB-PDCCH. Similarly, for uplink (UL) data transmission, information about resources scheduled by the network and needed by the UE for UL transmission is first conveyed on the NB-PDCCH and then the first transmission of the actual data by the UE on the narrowband Physical Uplink Shared Channel (NB-PUSCH or NPUSCH) is carried out after the final transmission of the NB-PDCCH. In other words, for both cases above, there is no simultaneous reception of control channel and reception/transmission of data channel from the UE's perspective.
In legacy cellular communication systems like High Speed Packet Access (HSPA) and LTE, a re-transmission procedure called Hybrid Automatic Repeat reQuest (HARQ) with soft combining is supported. After a data block is transmitted in one direction (e.g., between a UE and a radio base station) feedback on the decoding result is usually transmitted in the reverse direction, denoted as a HARQ feedback message. This feedback message is typically either a “binary” decoding result or a scheduling grant/assignment message. In cases where the feedback is a “binary” decoding result, the feedback may be in the form of an acknowledgement (ACK) indicating that data block decoding was successful, or a negative acknowledgement (NACK) indicating that data block decoding was unsuccessful. In cases where the feedback is in the form of a scheduling grant/assignment message, the scheduling grant/assignment message may request either a re-transmission (in the event that data block decoding is unsuccessful, similar to the NACK described above) or a transmission of a new data block that implicitly acknowledges that the previous data block was successfully decoded (similar to the ACK described above).
In some cases, HARQ feedback information could also be indicated by no transmission (DTX). In such a scenario, no transmission means either ACK or NACK (typically the latter) and transmitting something (e.g., a preamble or some other signal/code) could indicate an ACK. Lack of transmitting a HARQ feedback message could also be possible to indicate either a successful or unsuccessful decoded data block (i.e., ACK or NACK). The HARQ feedback (or lack of it) then triggers the re-transmission, or, if the data was received successfully and more data is available, a new data transmission could be started.
Typically, multiple so-called HARQ processes are used in parallel (e.g., in HSPA and LTE). A HARQ process is a stop-and-wait (SAW) HARQ entity that independently transfers data packets and waits for HARQ feedback before either a re-transmission or a new transmission is transmitted. In legacy LTE FDD, typically eight HARQ processes are supported per direction. The same applies to HSPA with 2 ms UL transmission time interval (TTI).
Synchronous HARQ operation means the retransmissions occur at a fixed time after the previous transmission. In asynchronous HARQ operation, on the other hand, the retransmissions can occur at any time after a previous transmission. In both legacy LTE and in HSPA, the UL uses synchronous HARQ and the downlink (DL) uses asynchronous HARQ.
To reduce UE battery consumption, a concept called connected mode discontinuous reception (DRX) is used, which allows the UE to go into sleep mode (i.e., no reception and/or transmission is required) during connected mode in LTE. The main idea is that when there has not been any transmission and/or reception activity (e.g., no transmissions/re-transmissions and no pending re-transmissions) for a period of time, the UE can go into sleep mode and only needs to be awake periodically for a short amount of time every DRX cycle to monitor the DL control channel. If new UL data becomes available, the UE can wake up at any time but needs to inform the network through configured UL resources (for example, a scheduling request could be triggered to be sent on Physical Uplink Control Channel (PUCCH)).
The DRX operation is defined in 3GPP TS 36.321, v. 13.0.0 for legacy LTE and controlled by a set of timers/parameters that are either pre-defined or sent to the UE. Specifically: onDurationTimer; drxStartOffset (from longDRX-CycleStartOffset in 3GPP TS 36.331, v. 13.0.0); longDRX-Cycle (from longDRX-CycleStartOffset in 3GPP TS 36.331, v. 13.3.0); shortDRX-Cycle; drxShortCycleTimer; drx-InactivityTimer; HARQ-RTT-Timer; and drx-RetransmissionTimer. Herein, citations to a particular version of the standard (e.g., TS 36.331, v. 13.0.0) are intended as representative versions available when the application was originally filed. However, other versions may also apply, as appropriate.
FIG. 1 illustrates an example of UE operation during connected mode DRX. More particularly, FIG. 1 (which is reproduced from 3GPP TS 36.321, v. 13.0.0) illustrates when the UE needs to be awake and monitor the DL control channel (denoted as PDCCH in the example of FIG. 1, but could be PDCCH and/or ePDCCH) during connected mode DRX cycle 105. In general, during DRX cycle 105 the UE monitors the DL control channel during OnDuration period 110 and sleeps during Opportunity for DRX 115. If new data is scheduled (in either UL or DL) during the OnDuration time 105, the UE goes out of DRX and starts a timer called drx-InactivityTimer.
FIG. 2 illustrates an example of legacy DRX operation. If new data 205 is scheduled (by DL control channel 210), drx-InactivityTimer 215 will be re-started, otherwise it will eventually expire and the UE enters DRX. In the example of FIG. 2, the UE enters DRX upon expiry of drx-InactivityTimer 215 if it has not detected PDCCH during the duration of drx-InactivityTimer 215. In addition, FIG. 2 illustrates the offset 220 between the HARQ data 205 (shown in the example of FIG. 2 as “New Data” 205) and the HARQ feedback 225 (shown in FIG. 2 as ACK transmission 225 in the UL 230). In LTE, offset between the HARQ data 205 and the HARQ feedback 225 is always N+4, i.e., always 4 ms (or equivalently sub-frames) after the data transmission at time occasion N.
FIG. 3 illustrates an example of legacy DRX operation if there are DL re-transmissions. In such a scenario, the UE uses two other timers: HARQ-RTT-Timer 305 and drx-RetransmissionTimer 310 to supervise the re-transmission(s). Note that these timers are independent of drx-InactivityTimer 215. When the re-transmission (shown in FIG. 3 as ReTx 315) is successfully decoded, drx-Retransmission Timer 310 is stopped/cancelled, as shown in the example of FIG. 3. Note that in the example of FIG. 3, after “New Data” 205 there could be activity for other UL/DL HARQ processes signaled on the PDCCH. If new data is scheduled on any of those, drx-InactivityTimer 215 is re-started.
FIG. 4 illustrates an example of legacy DRX operation when there is an UL re-transmission. In the example of FIG. 4, the UE receives UL grant 405 on DL control channel 410 while OnDuration Timer 410 is running. Upon receiving UL grant 405, the UE stops OnDuration Timer 410 and starts drx-InactivityTimer 215. In the example of FIG. 4, the UE performs UL transmission 420 (shown as “New Data” in the example of FIG. 4) associated with UL grant 405. After performing the UL transmission 420, the UE will enter DRX upon expiry of drx-InactivityTimer 215 if it does not detected PDCCH during the duration of drx-InactivityTimer 215.
In legacy LTE, no retransmission timers are needed if there is an UL re-transmission 425, as synchronous HARQ is used. Synchronous HARQ provides the exact timing on when the HARQ feedback (e.g., ACK 435 and/or NACK 430) and the re-transmission is scheduled. A new grant on DL control channel 410 (e.g., PDCCH) could also be given at the same sub-frame as NACK 430 is sent on the Physical Hybrid Indicator Channel (PHICH) and then the re-transmission is called “adaptive.” The N+4 offsets between UL grant 405 and UL transmission 420, between uplink transmission 420 and NACK 430, between NACK 430 and UL retransmission 425, and between UL retransmission 425 and ACK 435 are shown as elements 220a, 220b, 220c, and 220d, respectively.
Note that in the example of FIG. 4, after UL grant 405 there could be activity for other UL/DL HARQ processes signaled on downlink control channel 410 (e.g., PDCCH). If new data is scheduled on any of those, the drx-InactivityTimer is re-started (if used/running). Note, also that in some cases ACK 435 could also be an implicit acknowledgement, for example if a grant for new data is given for the HARQ process.
In 3GPP Release 13, a work item for enhanced Machine-Type Communication (eMTC) has been ongoing, in which changes have been made to HARQ operations as compared to legacy LTE. It has been decided that three parallel HARQ processes are supported. In addition, the UL HARQ has been changed from synchronous to asynchronous, and HARQ feedback is only implicit and received on M-PDCCH (i.e., no PHICH channel exists) earliest N+4 after the PUSCH transmission. As a result, changes are needed to how the UE should enter DRX when there is a re-transmission, as the timing of the HARQ feedback is no longer fixed.
In another work item in 3GPP Release 13 related to licensed-assisted access (LAA), it has also been identified that the UL HARQ needs to be changed from synchronous to asynchronous compared to legacy LTE. The impact of this is described in detail in 3GPP TR 36.889, v. 13.0.0 (and in particular section 7.2.2.2), which is hereby incorporated by reference in its entirety.
In LTE/eMTC all DRX parameters are semi-statically configured in the UE based on Radio Resource Control (RRC) signaling. Some dynamic change is supported through Medium Access Control (MAC) signaling to control the UE entering short/long DRX during the “Active time.”
A problem with existing approaches is that the HARQ/DRX design has been optimized for multiple HARQ processes and use cases where low latency is important and minimizing UE battery consumption has not been the main goal. If the same design is applied to a UE that only supports half-duplex operations, cross subframe scheduling and only one HARQ process, it would result in the UE being awake for a longer time than necessary for many traffic use cases that are typically used in MTC/IoT applications. For example, in many of the traffic use cases there are no simultaneous UL and DL data transfers. Instead, most use cases rely on a request-response type of traffic pattern where an IP packet is sent in one direction followed by a response in the other.
Further, according to existing approaches (both LTE and HSPA) the HARQ operation in the UL is synchronous. If the HARQ operation is changed to asynchronous, it is not known how long the UE shall wait for HARQ feedback after a transmission/re-transmission has been done. One approach would be to copy the DL design also for the UL (i.e., introduce similar timers (e.g., HARQ-RTT-Timer/drx-RetransmissionTimer) also for the UL). Although such an approach might be acceptable for legacy LTE use cases, it is not well suited for use cases in the area of MTC/IoT. These applications involve the use of new, simplified UEs with support for only half-duplex, one HARQ process and cross-subframe scheduling. Thus, a more optimized solution is desirable. The reason for this is that other solutions could reduce the UE battery/power consumption and therefore perform better if the properties of half-duplex, one HARQ process, only cross sub-frame scheduling and typical traffic patterns are utilized in the design.
One goal of NB-IoT is to re-use the legacy LTE (including eMTC changes) as much as possible. An important consideration is how the HARQ and connected mode DRX operations should work. If the legacy design is applied on NB-IoT this would lead to larger battery/power consumption for the UE. Further, since all the DRX-related timers are semi-static, there is very limited flexibility for the eNB to schedule HARQ transmissions/re-transmissions and HARQ feedbacks. If many UEs and/or UEs with different coverage levels (and thus different transmission duration times) need to be served, the previous approaches of having semi-static parameters are not flexible enough to enable short “active time” for UEs. Applying the same design as in legacy LTE would require the use of larger timer values, and thus the UE awake time would be longer resulting in larger battery/power consumption.